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(57) Abstract 



The invention provides for the first time a process for testing 
classes of an object-oriented program. Classes are tested by causing 
the tests interactively to input test commands with their method calls. 
It is also possible to check the test results interactively. Testability is 
obtained in that the necessary call parameters are found beforehand for 
all the methods permitted in the class and precautions are taken in the 
computer store to store and alter the possible parameters. The advantage 
is that testing can be performed interactively and not, as previously, in 
that the test program had to be once more corrected, translated and fixed 
after test evaluation, which took a great deal of time. The invention can 
advantageously be used in the development of communication software. 

(57) Zusammenfassnng 

Mit der Erfindung wird erstxnals ein Verfahren zum Testcn von 
Klassen eines objektorientierten Programmes zur Verfugung gestellt 
Klassen werden getestet, indem vom Tester Testkommandos mit 
denen Methodenaufrufe moglich sind, interaktiv eingegeben werden. 
die Oberprufung der Testergebnisse ist ebenfalls interaktiv moglich. 
Erreicht wird die Testbarkeit dadurch, dafi vorab fur alle in der 
Klasse erlaubten Methoden, die erfordcrlichen Atifrufporameter ermitelt 
werden, und dafi im Rechnerspeicher Vorkehrungen getroffen werden, 
urn die moglichen Parameter abzuspeichem und zu verandern. Der 
Vorteil besteht darin, daB interaktiv getestet werden kann, und nicht, wie 
bisher ublich das Testprogramm nach der Testausweitung zeitaufwehdig 
emeut korrigiert ubersetzt und gebunden werden mufi. Vorteilhaft 
kann die Erfindung bei der Entwicklung von Ko mmunikati on s- Software 
eingesetzt werden. 
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Verfahren zum Testen mindestens einer Klasse eines 
objektorientierten Programmes auf einem Rechner 

Mit dem zunehmendem Umfang von Systemlosungen im Rahmen von 
industriellen Grofcprojekten, wachst auch der Beitrag den die 
Software zur Losung liefert. Damit man grofie Sof twareprojekte 
effizient abwickeln kann, hat es sich als vorteilhaft erwiesen, 
diese Projekte in Teilprojekte zu unterteilen und einzelne 
Programme modular zu erstellen. Ein nicht unwesentlicher Aspekt 
bei der modularen Erstellung von Programmen ist auch, 
dafi einzelne Programmoduln von anderen Projekten leicht wieder 
verwertet werden konnen. In den vergangenen Jahren hat sich in 
diesem Zusammenhang besonders die Technik des objektorientierten 
Programmierens als vorteilhaft erwiesen. Eine Einfuhrung in die 
Grundlagen und die Namensgebung der objektorientierten 
Programmierung findet sich zum Beispiel in [1] . 

Im Zusammenhang mit der Wiederverwertbarkeit einzelner 
Programmoduln, kommt besonders der Qualitatssicherung dieser 
Programmoduln eine erhohte Bedeutung zu. Den Anf orderungen einer 
besonders fehlerfreien Qualitat einzelner Programmstrukturen wird 
durch besonders entwickelte Testverf ahren Rechnung getragen . Ein 
wesentliches Anliegen des Sof twaretestens ist es, die Qualitat 
der Software im Rahmen der Testabdeckung nachzuweisen . Urn den 
Tester bei seiner Arbeit zu unterstutzen, sind unterschiedlichste 
Testverf ahren denkbar. Man will mit diesen Testverf ahren einen 
durchgehenden Test der Software von einzelnen Programmoduln bis 
zum kompletten System ermOglichen . Insbesondere unterscheidet man 
dabei drei aufeinander aufbauende Tests: den Komponententest , den 
Integrationstest und den Systemtest . Der Komponententest hat das 
Ziel, Fehler in einzelnen Progammkomponenten zu finden. Bei den 
Komponenten handelt es sich herkommlicherweise urn ein oder 
mehrere Moduln, beispielsweise in der objektorientierten 
Programmierung urn Klassen. Der Komponententest wird durch den 
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Integrationstest , mit dessen Hilfe Fehler an den Schnittstellen 
und in der Kommunikation zwischen den getesteten Komponenten 

entdeckt werden, erganzt. Zum AbschluS kann ein Systemtest 
durchgefuhrt werden, welcher einen Test aus Kundensicht darstellt 
(z.B. der Test einer kompletten vermittlungstechnischen Anlage) . 
Er hat das Ziel die Stabilitat des gesamten ( Programm- ) Systems 
unter "Last" , d.h. realen bis extremen Bedingungen, zu testen. 

Im Rahmen der Technik des objektorientierten Programmierens wird 
der Komponententest durch ein Testverf ahren fur Klassen. 
bereitgestellt . Sinnvollerweise beginnt man mit dem Testen bei 
einzelnen Programmkomponenten, d.h. den Klassen. Setzt man beim 
Test eines Programmes auf nicht ausgetestete Klassen auf, so 
werden Fehler, die bei der Klassenimplementierung gemacht wurden, 
nicht oder nur sehr viel schwerer gefunden und entsprechend 
schwer behoben. Der Grund dafur liegt neben der schlechten 
Uberschaubarkeit des gesamten Programmes in der Vermischung 
dieser funktionalen Fehler, mit denen, die beim Zusammenspiel der 
einzelnen Objekte auftreten (Komunikations-bzw. Schnittstellen- 
fehlern) . Ein weiterer wesentlicher Grund fur gut ausgetestete 
Klassen ist die daraus resultierende gesteigerte Bereitschaf t , 
diese Klassen wieder zu verwenden. Qualitativ schlechte Software 
eignet sich of f ensichtlich .nicht zur Wiederverwendung . 

Klassen sind als Testlinge in der Regel fur sich alleine nicht 
ablauffahig und damit ohne zusatzlichen Aufwand auch nicht mit 
einem Debugger eines Betriebssystems zu debuggen. Da diese 
Testlingsklassen nur Programmstrukturen darstellen, ist es 
zwingend erf orderlich, fur ihren Test Objekte aus ihnen 
abzuleiten. Sie werden dann getestet, indem bei den Objekten . 
entsprechende Methoden aufgerufen und ausgefuhrt werden. Die 
Parameter eines Methodenauf ruf s zusammen mit den Werten der 
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Datenkomponenten eines auf zuruf enden Objekts scellen dann die 
Testdaten dar. 

Die Technik des objektorientierten Programmierens ist 
vergleichsweise jung. Es gibt deshalb keine technischen Verfahren 
zum testen von Klassen objektorientierter Software. Wurde ein 
Programmierer auf herkommliche Weise eine Klasse testen wollen, 
so mufite er zunachst einen Test fall generieren, d.h. ein Programm 
schreiben, welches aus einer Klasse ein Objekt instanziert . 
Weiterhin mufite er im Vorfeld des Tests Methodenauf ruf e inklusive 
Parameterwerte fur dieses Objekt in dieses Programm einarbeiten, 
welche mdglichst genau auf die Fehler, die er zu finden hofft, 
abgestimmt waren . Anschliefiend wurde er dieses Programm 
ubersetzen und binden mussen. Nach dem Testlauf wurde dann eine 
Auswertung erfolgen. Falls der Test keine Aussagen uber die 
Funktionsf ahgikeit dieser Klasse zulieSe, muSte er den gesamten 
Vorgang erneut durchfuhren. 

Die der Erfindung zugrundeliegende Aufgabe besteht darin, ein 
interaktives Verfahren zum Testen mindestens einer Klasse eines 
objektorientierten Programmes auf einem Rechner anzugeben. 

Diese Aufgabe wird gemafi den Merkmalen des Patentanspruchs 1 
gelost . 

Alle ubrigen Weiterbildungen der Erfindung ergeben sich aus den 
Unteranspruchen . 

Besonders vorteilhaft an dem angegebenen Verfahren ist die 
Tatsache, daS Klassen zeitlich vor und unabhangig von ihrer 
eigent lichen Anwendung in objektorientierten Programmen getestet 
werden konnen . 
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Besonders vorteilhaft an der Anwendung des erf indungsgemaSen 
Verfahrens ist die Tatsache, .dafi bereits im Vorfeld des Tests 
alle fur den Test mafigeblichen Kenngrofien erfaSt werden und daS 
das Testprograinm nur einmal ubersetzt und gebunden werden muS. 

Urn das Zusammenspiel auch mehrerer Klassen sinnvoll testen zu 
konnen, ist im erf indungsgemaSen Verfahren gunstigerweise 
vorgesehen, die Methodeninf ormation aller am Test beteiligten 
Klassen fur die in der externen Methodenschnittstelle der 
beteiligten Klassen definierten Methoden zu gewinnen. 

Besonders vorteilhaft ist am erf indungsgemaSen Verfahren, daS es 
im Vorfeld eine Speicherzuweisung fur die Objektinitialisierung 
oder Methodenauf ruf e vorsieht. 

Eine gunstige Form der Speicherzuweisung geschieht beispielsweise 
uber pointer, die dann wahrend des Testbetriebs umdefiniert 
werden konnen. 

Weiterhin ist es gunstig, daS das erf in.dungsgemaSe Verfahren 
einen Zugriff auf obj ektinterne Datenkomponenten vorsieht, da 
diese normalerweise fur einen Tester wegen des, beim 
objektorientierten Programmieren ublichen, Data Hidings nicht 
zugangl i ch s ind . 

•Weiterhin ist es beim angegebenen Verfahren guns tig, daS ein 
Debugger angeschlossen ist, sodaS beim Test entdeckte Fehler 
sofort mit zusatzlicher Zuhilf enahme des Debuggers analysiert und 
lokalisiert werden konnen. 

Um die Funktionsweise einer Klasse moglichst vollstandig Testen 
zu konnen, sieht das erf indungsgemafie Verfahren sinnvollerweise 
auch eine Gewinnung der Methodeninf ormation fur generische und 
vererbende Klassen vor. 



WO 94/14117 



PCT/EP93/03450 



5 

Im folgenden wird die Erfindung anhand von Figuren und Beispielen 
weiter erlautert. 

Figur 1 zeigt ein Ausf uhrungsbei spiel eines erf indungsgemaSen 
Verf ahrens . Dieses Ausf uhrungsbeispiel kann sich beispielsweise 
auf eine Vermitttlungseinrichtung beziehen. Die 
Programmiersprache, in der der Rechner programmiert wird, sei 
beispielsweise Object CHILL ([2]). 

Figur 2 zeigt als Beispiel ein Programmlisting 

Figur 3 zeigt ein Blockdiagramm eines erf indungsgemafien 
Verf ahrens 

Wie in Figur 1 dargestellt, wird beispielsweise aus einer 
Klassenspezif ikation KS mit Hilfe eines Generators G 
Methodeninf ormation gewonnen und diese Methodeninf ormation dazu 
benutzt, Variablenspeicher fur die entsprechenden Parameter der 
Methodenauf ruf e und die Objekte der Testlingsklassen selbst in 
Form eines Testrahmens TR bereitzustellen . Anschliefiend wird mit 
Hilfe eines Ubersetzers U der Testrahmen TR zusammen mit einem . 
Kommandointerpreter KI ubersetzt, wodurch ein fertiges 
Testprogramm TP entsteht . Dieser Kommandointerpreter KI ist 
beispielsweise fur eine Testkommandosprache (die Bef ehlssyntax 
ist weiter hinten in der Beschreibung unter "Eingaben" erlautert) 
entworfen. So kann der Testende einfach Testszenarien erstellen, 
Beispielsweise kann der Kommandointerpreter folgende Befehle 
zulassen: 

<statements> : : = {<command> n ; "} . 

<coirmand> : : = <control.cmd> | <general_cmd> | <regtest_crrd> | 

<output_cmd> | <modclss-cmd> | <assign.cmd> 
<methcall_cmd> 
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::= Do WHILE <chars> " ; " <statements> OD 
IF <chars> THEN <statements> 

[ELSE <statements>] FI . 

: : = DCL <chars> | 
END | 

PROTSTATUS | 

PROTOCOL [TERM] [ALL] [INP] [OUT] | 
INPUT (INP1 | INP2 | INP3 | INP4 | INP5) | 
RETURN | 
EXIT | 

HELP [<cmd_keyword>] 
IDS_ON. 

SAY (<idsvar> | <string>) | 
WRITE (<idsvar> | <string>) . 

: : = REGTES TSTART | 
REGTESTEND 

DC L , OBJ <objvar> <ident> [<parlist>] .| 
DCL _REF-OBJ <idsvar> REF <ident> | 
DISPOSE-OBJ objvar | 
ASS IGN-REF.OBJ <objvar> <idsvar> | 
ASS IGN. DERE F _ PTR <idsvar> <objvar> | 
SHOW O BJ <objvar> | 
QBJ_LIS1 (<ident> | ALL | 
OBJ REF LIST (<ident>) I ALL) | 

CLASSJLI23L 

::= <idsvar> " : = ■' (methcall_cmd> | <chars>) | 
<objvar> M (<objvar> | <methcall_cmd>) . 
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<methcall_cmd> ::= <objvar> tt . " <ident> <parlist>. 

<cmd_keyword> : : = DCL | END | . . .| £LASS_LIST. 

<param> ::= <objvar> | <idsvar>. 

<ident> ::= <letter> { <letter> I <number> I " _ M } . 

<idsvar> n %" {<letter> I <number> I <special>}+ . 

<objvar> ::= n &" <letter> {<letter> | <number> | _ }. 

<string> ::= M ' " {<beliebiges Zeichen des EBCDIC-Codes 

aufier ■>}"'» . 

<chars> ::= {<beliebiges Zeichen des EBCDIC-Codes 

aufier;>} . 

<letter> ::= " A 11 | M B 11 | ... | "Z". 

<number> ::= "O" | "l tt | . . . | "g tt . 

<special> ::= <Fur IDS-Variablenamen einschlieSlich Kompo- 

nenten erlaubte Sonderzeichen> , 

Beispielsweise werden im erf indungsgemaSen Verfahren zwei Arten 
von Variablen unterschieden. Zum einen die reinen IDS-Variablen 
(IDS: Interaktives Debugging System), die wie gewohnt deklariert 
und benutzt werden konnen, und zum anderen Objekte, die als 
Instanzen von Testlings- oder Parameterklassen uber das Kommando 
DCL -OBJ deklariert werden. 

Beispielsweise Variable aus mitgebundenen Moduln konnen uber IDS. 
und in Bool'schen Bedingungen von Schleifen und Verzweigungen 
oder auf der rechten Seite von Zuweisungen mit IDS verwendet 
werden. Die Verbindung zwischen den mit Q£1l-QBJ vereinbarten 
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Objekten mit IDS wird durch IDS-Pointer beispielsweise vom Mode 
"REF Testingsklasse" (mit DCL_REF_OBJ zu vereinbaren) und den zwei 
Kommandos AS£IGN_£EF_QBJ und ASSIGN _DE£EF_£TR hergestellt. Bei- 
spielsweise werden Operatoren der Testsystem Kommandosprache auf 
IDS-Operatoren abgebildet. 

Im erf indungsgemafien Verfahren konnen beispielsweise folgende 
Befehle zu Objektbearbeitung vorgesehen sein, die vom Testenden 
interaktiv eingegeben werden und die eine hohe Flexibilitat beim 
Test gewahrleisten.Die Testeingaben durch den Testenden und die 
von ihm getatigten Aufrufe werden sinnvollerweise gesondert 
verwaltet. Beispielsweise ist eine Objektverwaltung vorgesehen, 
um die Zuweisung von Testobjekten in der Kommandosprache zu 
Rechner-Objekten sicherzustellen . Weiterhin kann auch vorteilhaft 
eine Auf ruf bearbeitung vorgesehen sein, welche die Konsistenz von 
Test-Methodenauf ruf en mit hardwareseitig ablaufenden Programmen 
sicherstellt . Es ist dazu nicht erf orderlich, das Testprogramm 
neu zu generien. 

Kommandos zur Objektbearbeitung 

Vereinbarung eines Objekts einer MODULE -Klasse 

DCL OBJ Objektname Klassenname " ( " Parameterliste" ) " 

Mit diesem Kommando wird ein Objekt auf Ebene der Kommandosprache 
bereitgestellt . Die Parameterliste gibt die Parameter fur den 
Konstruktorauf ruf an. Sie kann ent fallen, dann wird der 
Standardkonstruktor aufgerufen. Ansonsten gelten fur sie die 
gleichen Regeln wie beim Methodenauf ruf . 
Der Objektname muS aus dem Zeichen & gefolgt von einem 
GroSbuchstaben und dann hochstens noch 2 9 GroSbuchstaben, Ziffern 
oder Unterstrichen bestehen, ansonsten wird die Fehlermeldung 
"ILLEGAL OBJECTNAME " ausgegeben. Die Klasse muS bei der Erzeugung 
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des Testrahmens mit berucksichtigt worden sein, ansonsten wird 
die Fehlermeldung "UNKNOWN CLASS" ausgegeben. Falls schon ein 
Objekt mit dem angegebenen Namen vereinbart wurde, wird die 
Fehlermeldung "OBJECT ALREADY DECLARED" ausgegeben. Der 
Kommandoname DCL_OBJ wurde zur Unterscheidung vom IDS -Kommando 
DCL gewahlt . 

Vereinbarung eines Pointers auf Objekte 

DCL REF O BJ Pointername REF Klassenname 

Der vereinbarte Pointer ist eine IDS -Variable, von deren Existenz 
die Objektverwaltung Kenntnis hat. Die Regeln von IDS sind 
einzuhalten. 

Der Pointermode auf Klassen, von denen Objekte vereinbart werden 
konnen, wird im Testsystem intern deklariert . Beim Loschen von 
Objekten mit dem DISPOSE_OBJ_Kommando wird gepruft, ob noch mit 
DCL_REF.OBJ fur die Klasse des zu loschenden Objekt s vereinbarte 
Pointer auf dieses zeigen (vgl. DISPOSE.OBJ.Kommando) . 

Loschen eines Objekt s einer MODULE-Klasse 

DISPOSE QgJ Ofriekt,nflirifi 

Mit diesem Kommando wird ein zuvor mit DCL.OBJ instantiiertes 
Objekt wieder geloscht. Das Objekt mufi zuvor erzeugt worden sein, 
sonst liegt ein Fehlerfall vor, der mit "OBJECT UNDEFINED" 
gemeldet wird. Falls noch mit DC_LREF_OBJ fur die Klasse des zu 
loschenden Objekts vereinbarte Pointner auf das Objekt zeigen, 
wird das Kommando nicht ausgefuhrt und die Fehlermeldung "OBJECT 
YET REFERENCED BY POINTER" ausgegeben. Es wird aber nicht 
gepruft, ob noch andere als mit DCL_REF_OBJ vereinbarte Pointer 
auf das Objekt existieren. 
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Ubergabe der Adresse eines Objekts 

A£SIGN_REF_QBJ Objektname IDS-Variable 

Das Kommando schreibt die Adresse des angegebenen Objekts in die 
IDS-Variable. Diese mufi mit DCL_REF_OBJ als Pointer auf die 
Klasse des angegebenen Objekts vereinbart worden sein, sonst wird 
die Fehlermeldung "UNKNOWN IDS- POINTER " ausgegeben. (Kein 
Polymorphismus fur die mit DCL_REF_OBJ Pointer!). Das Objekt mug 
zuvor mit DCL.OBJ erzeugt worden sein, sonst wird die 
Fehlermeldung "UNKNOWN OBJECT" ausgegeben. 

Nach dem Kommando zeigt die IDS-Variable auf das Objekt. Durch 
dieses Kommando wird fur den Tester die Verbindung zwischen IDS 
und den Objekten der Kommandosprache hergestellt. 

Ubergabe der Daten eines derefenzierten Pointers 

AS_S_IGN_DEREF_PTR IDS-Variable Objektname 

Das Kommando kopiert die Daten des Obekts, auf das der Pointer 
zeigt, in das angegebene Objekt. Durch- dieses Kommando wird fur 
den Tester die Verbindung zwischen IDS und den Objekten der 
Kommmandosprache hergestellt. 

Die IDS-Variable muS mit DCL_REF.OBJ als Pointer auf die Klasse 
des angegebenen Objekts vereinbart worden sein, sonst wird die 
Fehlermeldung "UNKNOWN IDS-POINTER" ausgegeben. (Kein 
Polymorphismus fur die mit DCL_REF_OBJ vereinbarten ! ) . Die IDS- 
Variable muS auch tatsachlich auf ein Objekt dieser Klasse 
zeigen. Dies kann vom Testsystem nicht uberpruft werden! Das 
angegebene Objekt muS zuvor mit DVL-OBJ erzeugt worden sein, 
sonst wird die Fehlermeldung "UNKNOWN OBJECT" ausgegeben. 



Ausgabe der Daten eines Objekts 
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Objektname 

Das Kommando veranla£t die Ausgabe der Datenat tribute des 
angegebenen Objekts in die Protokolldaten ALL, OUT und auf 
Terminal, falls sie aktiviert sind (dazu Kommando PROTSTATUS). Es 
wird mit dem IDS -Kommando DISPLAY realisiert . Das Objekt muS 
zuvor mit DCL.OBJ erzeugt worden sein, ansonsten wird die 
Fehlermeldung "UNKNOWN OBJECT" ausgegeben. 

Eine weitere Moglichkeit, Objektdaten auszugeben, ist das 
Anzeigen deref erenziert IDS-Pointer, die auf das Objekt zeigen, 
mittels der Kommandos SAY und WRITE. 

Auf ruf gewdhnlicher Methoden 

Objektname .Methodenname " ( "Parameterliste" ) " 

Bei dem angegebenen Objekt wird die Methode mit den Parametern 
der Parameterliste aufgerufen. Es muE zuvor mmit DCL-OBJ erzeugt 
worden sein. Als Parameter sind nur IDS-Variablen oder Objekte 
(die zuvor in der Kommandosprache vereinbart wurden) zugelassen. 
Bei fehlerhaften Modes wird die Fehlermeldung " PARAMETERMODES DO 
NOT FIT TO METHODNAME " ausgegeben. Wegen moglichen Overloadings 
in den Methoden der Testlingsklasse kann der Mode-Fehler im 
allgemeinen nicht genauer lokalisiert werden. Die Parameter sind 
durch Kommata zu trennen, derart, daS zwischen zwei direkt 
auf einanderf olgenden Parametern je genau ein Komma steht. 
od 

Auf ruf einer Methode mit Ergebnis 

Variable : = Objektname .Methodenname ■( "Parameterliste" ) " 
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Es gelten die gleichen Regeln wie beim Aufruf gewohnlicher 
Methoden (s .o. ) . 

Die Variable, der das Ergebnis zugewiesen wird, muS eine IDS- 
Variable Oder ein zuvor mit DCL_OBJ vereinbartes Objekt passenden 
Modes sein, sonst wird eine Fehlermeldung ausgegeben. 

Zuweisung mit Objekt en 

Objl := 0bj2 

Den Datenkomponenten von Objl werden die entsprechenden Werte von 
0bj2 zugewiesen. Die beiden Objekte mussen zuvor mit DVL_OBJ 
vereinbart worden und von der selben Klasse sein, sonst wird die 
Fehlermeldung " UNKNOWN OBJECT Objektname" bzw. " MODE -MIS SMATC H " 
ausgegeben . 

Information iiber Objekte 

OB J LIST Klas s enname 

Dieses Kornmando veranlaSt die Ausgabe der Namen aller Objekte, 
die aktuell fur die angegebene Klasse vereinbart sind. Statt 
Klassenname kann auch ALL angegeben werden, worauf zu samtlichen 
Klassen, fur die eine Obj ektverwaltung existiert, die Objektnamen 
ausgegeben werden. Falls fur die Klasse mit dem angegebenen Namen 
keine Objektverwaltung generiert wurde, wird die Fehlermeldung 
" UNKNOWN CLASS " ausgegeben.. 

Information iiber Objektpointer 

QBJ_REF LIST Klassenname 

Dieses Kornmando veranlaSt die Ausgabe aller Pointernamen, die 
aktuell zur angegebenen Klasse mit dem Kornmando DCL_REF OBJ 
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vereinbart sind. Statt Klassennamen kann auch ALL angegeben 
werden, worauf samtliche mit DCL REF OBJ vereinbarten 
Objektpointernamen ausgegeben werden. Falls fur die Klasse mit 
dem angegebenen Namen keine Objektverwaltung generiert wurde, 
wird die Fehlermeldung "UNKNOWN CLASS " ausgegeben. 

Information xiber Klassen 

CLASS LIST 

Dieses Koinmando veranlafit die Ausgabe aller Klassennamen, fur die 
eine Objektverwaltung generiert wurde. 

Die hier gemachten Ausfuhrungen sind nur als Beispiel fur eine 
Ausfuhrungsf orm des erf indungsgemafien Verfahrens aufzufassen und 
berucksichtigen die spezielle Namensgebung von Object -CHILL. Sie 
sind auf andere objektorientierte Programmiersprachen wie zum 
Beispiel C++, Eiffel, SIMULA oder Smalltalk direkt ubertragbar. 
Es kann beispielsweise ohne Beschrankung der Allgemeinheit auch 
vorgesehen sein, andere Kommandos fur einen Testkommando- 
Interprerter vorzusehen. Besonders wichtig ist, daS nur einmal 
ein Testprogramm ubersetzt werden muS und dafi der Tester durch 
das erf indungsgemaSe Verfahren die Moglichkeit erhalt, samtliche 
fur die Klassentests erf orderliche Test f unktionen interakt iv 
auszulosen. Interaktiv kann in diesem Zusammenhang auch bedeuten-, 
daS er Testkommandodateien generiert und diese startet und mit 
entsprechenden Abbruchkriterien versieht. 

In Figur 2 ist ein Testbeispiel des erf indunsgemaSen Verfahrens 
als Programmli sting aufgefuhrt. Es enthalt die Klassen- 
vereinbarung und die entsprechenden Kommandos fur den Test in- 
terpreter . 

In diesem Beispiel wird die generische Klasse STAGENLS uber ihre 
zwei Auspragungen STAINTLS und STATEXLS getestet . 
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Fur den Generator G dient eine Datei als Eingabe, die drei 
Klassenspezif ikationen Member 1), 2) und 3) wie gezeigt als 
Inhalt hat (die Reihenfolge der Members in der Datei ist 
unerheblich! ) . ■ 

Die Klasse STATEXLS importiert aus einem CHILL-Modul TEXMODE. Der 
exportierende Modul ist keine Eingabe fur den Generatorlauf . 

Bei diesem Beispiel werden zwei Objektverwaltungsklassen 
OMCL001S und OMCL002S und zwei Auf rufbearbeitungsklassen MCCL001S 
und MCCL002S generiert, weil nur zwei Klassen auftreten, von 
denen Objekte instantiiert und dort Methoden aufgerufen werden 
konnen, namlich STAINTLS und STATEXLS . Bei der' oben angegebenen 
Reihenfolge der Memberdateien gehoren die Klassen . . . 001S zu 
STAINTLS und die ... 002S zu STATEXLS. 

Figur 3 zeigt anhand eines Blockdiagrammes das Zusammenwirken 
verschiedener Komponenten, bei der Durchfuhrung eines 
beispielhaft ausgebildeten erf indungsgemaSen Verfahrens. 

An oberster Stellebef indet sich hier der Kommandointerpreter KI, 
welcher Eingaben einer Testperson interpretiert . 
Die Objektverwaltung OV und die Auf ruf verwaltung AV stellen die 
Konsistenz von Testlingen T mit dem Testszenario eines Testenden 
sicher. Dies geschieht, indent sie beispielsweise Speicherbereiche 
im Rechner uber Pointer zuweisen, oder diesen Speichebereichen 
namen zuordnen. So gewahrleisten sie den sicheren Ablauf der 
auszuf uhrenden Methoden. 
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4 EINGABEN 



4.1 Die Kommandosprache des Testsyst 



4.1.1 Allgemeine Konventionen 



Die Kommandosprache des Testsystems ist an CHILL und an IDS 
angelehnt. Dies bedeutet insbesondere , daS 

- der gleiche Zeichensatz verwendet wird, d.h. fur Schliisselworter 
und Bezeichner nur GroBbuchstaben zulassig sind, 

- alle Kommandos durch ein Semikolon abgeschlossen werden, 

- Kommentare wie Leerzeichen (Blanks) behandelt werden, 

- Blanks zwischen Schliisselwortern oder Bezeichnern angegeben 
werden miissen, wahrend sie zwischen Operatoren wegbleiben 
konnen. 



Zusatzlich werden folgende Festlegungen getroffen: 

- Zeilentrenner werden wie Blanks behandelt, d.h. bei einem 
mehrzeiligen Kommando wird nach dem 80. Zeichen (entspricht 
einer MVS-Zeile) ein Blank eingefiigt. Somit endet ein Wort 
spatestens am Zeilenende. 

- Die im folgenden aufgefiihrten Langen verstehen sich als 
Maximalwerte. 

Bezeichner sind maximal 31 Zeichen lang. 

Strings konnen eine Zeile (80 Zeichen) lang sein, wenn sie mit 
den Kommandos SAY bzw. WRITE ausgegeben werden. 

Boolesche Bedingungen in Schleifen und Verzweigungen, Ausdrucke 
und Variablendeklarationen diirfen 190 Zeichen nicht iiberschrei- 
ten, da diese mit Hilfe von IDS ausgewertet bzw. deklariert 
werden . 

- Erfolgreich eingegebene Kommandos werden nicht explizit 
guittiert, sondern es wird die Eingabe des nachsten Kommandos 
erwartet. Ausnahmen hierzu bilden lediglich die Kommandos 
END, REGTESTSTART und REGTESTEND. 

- Fehlerhafte Kommandos werden durch entsprechende Meldungen ange- 
zeigt, wobei implizite Fehlerkorrekturen nicht durchgefiihrt 
werden. Nach einem fehlerhaften Kommando erwartet der Interpre- 
ter das nachste Kommando im Terminalmodus , d.h. Komraandodateien 
werden unmittelbar nach einem Fehler verlassen. Tritt der Fehler 
in Kontrollstrukturen auf, werden diese genau wie das Kommando 
abgebrochen. .Weitere Kommandos in der gleichen Zeile werden 
ignoriert. -Fehlerhafte "Kommandos wahrend des. Regressionstestes 
fuhren zum Abbruch des Regressionstests . (vgl. Kapitel 6) 
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4.1.2 Zur Beschreibung der Kommandosprache 

Die Beschreibung der Kommandos ist an die erweiterte Backus-Naur- 
Form (EBNF) angelehnt, dabei gelten folgende Regeln: 

- Schliisselworter der Kommandosprache werden in Groflbuchstaben 
geschrieben. 

- Alternativen werden durch dargestellt, z.B: 

Com hat folgende Form: FORM1 | FORM2 , d.h. das Kommando Com 
kann in der Form FORM1 oder FORM 2 eingegeben werden. 

- Teile, die weggelassen werden konnen, werden in und 'V 
geklammert. 1 
Z.B.: Com hat folgende Form: TEIL1 [ TEIL2] , d.h. das 
Kommando Com kann in der Form TEIL1 oder TEIL1 TEIL2 daraestellt 
werden. y 

- Zusammengehorige Teile werden in ' ( ' und ')' geklammert. 
Z.B.: Com hat folgende Form: (TEIL1 | TEIL2) TEIL3, d.h. das 
Kommando Com kann in der Form TEIL1 TEIL3 oder TEIL2 TEIL3 
dargestellt werden. 

- Bei Kommandos oder Kommandoparametern, die abgekiirzt werden 
konnen, ist die Abkiirzung der unterstrichene Teil des Namens 
Z.B. kann KURZFORM durch KURF abgekiirzt werden 



4.1.3 Die syntax im oberblick 

Die Syntax der Kommandosprache ist ebenso wie die einzelnene 
Kommandos in den folgenden Kapiteln mittels EBNF beschrieben 
Zusatzlich werden folgende Festlegungen getroffen: 

- Non-Terminal-Syrobole, die dazu dienen, die Grammatik struktu- 
riert gliedern zu konnen, werden in spitze Klammern ('<' und 
'>') gefaBt. v 

- Terminal -Symbole sind Symbole, die zur TeS-Kommandosprache 
gehoren. Die Schliisselworter werden groB geschrieben und 
sonstige Symbole in Anf iihrungszeichen (z.B. ": = ») eingeschlossen 

- Die links vom Metazeichen '::=' stehenden Non-Terminal -Symbole 
konnen durch die rechte Seite ersetzt werden. Die Grammatik ist 
kontextfrei, d.h. auf der linken Seite stehen keine zusatzlichen 
Terminal -Symbole. 

- Symbole, die beliebig oft (auch O-mal) wiederholt werden diirfen 
werden m '(' und ')' geklammert. Folgt der schlieBenden Klammer 
em + , so bedeuted dies, daB das Symbol mindestens einmal 
wiederholt werden muB. Folgt eine Zahl x, so muB der geklammerte 
Teil genau x-mal wiederholt werden. 
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- Das Metasymbol '.' zeigt das Ende einer Regel an. 

- Anstelle des Non-Terminal-Symbols <chars> wird eine beliebige 
Zeichenfolge erwartet, die zur Auswertung an IDS iibergeben wird 
Diese Zeichenfolge wird vom Testsystem nicht syntaktisch 
analysiert • 



Grammatik der Kommandosprache fur den MODULE- Kl ass en-Test : 



<statements> 
<command> 

<control_cmd> 
<general_cmd> 



<output_cmd> 
<regtest_cmd> 
<modclss cmd> 



<assign_cmd> 



: = { <command> " ; " ) . 

:= <control_cmd> | <general_cmd> | <regtest_cmd> 
<output_cind> | <modclss_cmd> | <assign_cmd> | 
<methcall_cmd> 

:= DO WHILE <chars> " ; " <statements> OD | 
IF <chars> THEN <statements> 

[ELSE <st:atements>] FI. 

= DCL <chars> | 
END | 

PROTSTATUS | 

PROT OCOL [TERM] [ALL] [INP] [OUT] | 
INPUT (INP1 | INP2 | INP3 | INP4 | INP5) | 
RETURN | 
EXIT | 

HELP [ <cmd_keyword> ] | 
IDS_ON. 

:= SAY (<idsvar> | <string>) | 
WRITE (<idsvar> | <string>) . 

:= REGTESTSTART | 
REGTESTEND. 

:= DCL _OBJ <objvar> <ident> [<parlist>] | 
DCL_REF_OBJ <idsvar> REF <ident> | 
DISP OSEOBJ <objvar> | 
ASS IGN_REF_OBJ <objvar> <idsvar> | 
AS S I G N_ DERE F_ PTR <idsvar> <objvar> | 
SHOW _OBJ <objvar> 
OBJ LIST (<ident> ALL) | 
OBJ_REF_ LIST (<ident> | ALL) | 
CLASS LIST , 

:= <idsvar> " :=" (<methcall_cmd> | <chars>) | 
<objvar> " :=" (<objvar> | <methcall_cmd>) . 



<methcall_cmd> ::= <ob j var>" . "<ident> <parlist>. 
<cmd_keyword> ::= DCL | END | ... | CLASS_ LIST . 
<parlist> ::= "■(" [ <param> { " , " <param>) ] " ) " 



<param> 



= <objvar> | <idsvar>. 
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Pa tent anspruche 

1. Verfahren zum Testen mindestens einer Klasse eines objekto- 
rientierten Programmes auf einem Rechner, 

a) bei dem aus mindestens einer Klassenspezif ikation 
eine Methodeninf ormation uber mindestens eine Methode 
und deren zugehorige Auf rufparameter gewonnen wird, 

b) bei dem mit Hilfe der Methodeninf ormation ein Bestandteil 
eines Testprogramms erzeugt wird, welcher mindestens eine 
Zuweisung von beim Testen erf orderlichen Rechnerbetriebsmitteln 
sicherstellt , 

c) bei dem ein Testprogramm erzeugt wird, das als einen 
Bestandteil einen Kommandointerpreter enthalt, welcher von einem 
Testenden eingegebene Testkommandos interpretiert , und das als 
einen weiteren Bestandteil den unter b) erzeugten Bestandteil des 
Testprogramms enthalt 

d) und bei dem das Testprogramm mit Hilfe der Testkommandos zum 
Testen der Klasse verwendet wird. 

2. Verfahren nach Anspruch 1, bei dem die Methodeninf ormation 
zumindest fur alle uber eine externe Methodenschnittstelle 
exportierten Methoden, jeder einzelnen von gemeinsam zu testenden 
Klassen gewonnen wird. 

3. Verfahren nach einem der Anspruche 1 oder 2, bei dem ein 
Rechnerbetriebsmittel Speicher ist. 

4. Verfahren nach einem der Anspruche 1 bis 3, bei dem die 
Zuweisung der Betriebsmittel uber Pointer erf olgt . 

5. Verfahren nach Anspruch 1, bei dem der Kommandointerpreter 
mindestens einen in einem Betriebssystem des Rechners vorhandenen 
Debugger benutzt. 
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6. Verfahren nach einem der Anspruche 1 bis 5, bei dem mindestens 
eine interne Datenkomponente von mindestens einem aus einer 
Klasse abgeleiteten Objekt gelesen und/oder eingeschrieben wird. 

7. Verfahren nach einem der Anspruche 1 bis 6, bei dem die 
Methodeninformation fur mindestens eine Klasse mit mindestens 
einer ererbten Methode, auch aus mindestens einer vererbenden 
Klasse gewonnen wird, 

8. Verfahren nach einem der Anspruche 1 bis 7 fur mindestens eine 
aus einer generischen Klasse abgeleitete Klasse, bei dem die 
Methodeninformation auch fur mindestens eine Methode aus der 
generischen Klasse gewonnen wird. 
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FIG 2 



Member 1) 

STAGENLS : GENERIC 

SYNMODE ELEMMODE » ANY_ASSIGN; 

MODULE CLASS 

GRANT POP, TOP, ISEMPTY, PUSH PREFIXED STAGENLS; 
STAGENLS : CONSTR() ; END STAGENLS; 

POP : PROC() ; 
END POP; 

TOP : PROC() RETURNS (ELEMMODE) ; 
END TOP; 

PUSH : PROC (EL ELEMMODE) ; 
END PUSH; 

ISEMPTY : PROC() RETURNS (BOOL) ; 
END ISEMPTY; 

SYNMODE STACKPTRMODE ■ REF STACKELMODE; 
SYNMODE STACKELMODE = STRUCT ( 

EL ELEMMODE , 

NEXT STACKPTRMODE) ; 
DCL ANCHOR STACKPTRMODE; 

END STAGENLS; 

Der BODY von STAGENLS ist nicht Eingabe fiir den 
Testrahmengenera tor J 



Member 2) 

STAINTLS : MODULE CLASS « STAGENLS 

ACT_GEN_PART 

SYNMODE ELEMMODE « INT; 

END STAINTLS; 



Member 3) 



STATEXLS : MODULE CLASS = STAGENLS 

SEIZE TEXMODE; 

ACT_GEN_PART 

SYNMODE ELEMMODE - TEXMODE; 
END STATEXLS; 
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